Configurable payment tokens

ABSTRACT

Methods and systems are disclosed for the generation and use of merchant-customizable token formats that define tokens that represent credit card and other payment numbers in online transactions. The tokens, which are used instead of the card numbers themselves for security, can be specified by the token format to have a certain number of characters, have certain fields reserved for major card identifiers, use encryption and/or randomization, be alphanumeric, and have other formatting. The customized tokens can be used with legacy equipment that uses longer or shorter card numbers than the standard sixteen-digit payment card number format and can be less likely to be recognized as related to card numbers by identify thieves.

CROSS-REFERENCES TO RELATED APPLICATIONS

NOT APPLICABLE

COPYRIGHT

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND

1. Field of the Art

Generally, the present application relates to financial data processingand presentation thereof. Specifically, methods, systems, and devicesare presented for merchant-customizable token codes used for onlineshopping and preventing identity theft.

2. Discussion of the Related Art

Accepting credit card, debit card, prepaid card, and other payment cardsis a given for many retail merchants. For online merchants, acceptingPayPal® payments, Google Checkout™ payments, and other alternateelectronic payment types in addition to traditional credit card paymentsis becoming more common. Interfacing with the plethora of payment brandsthat customers expect to be available for payment transactions can bedaunting, especially given the regulatory burden of financialregulations, industry standards, and security considerations.

Some merchants contract with third-party payment services in order tofacilitate interfacing with the different types of payment networks.CyberSource of Mountain View, Calif., is one such third party paymentservice.

Third-party payment services not only take care of maintaininginterfaces between a contracting merchant and payment networks, theyalso offer other services such as risk management, hosted order pages(e.g., redirected online checkout web pages), and silent order posts(e.g., secure fields for a merchant's online checkout web page). Theseservices are in addition to servicing the day-to-day paymenttransactions of merchants.

In a typical payment transaction, a merchant sends an authorizationrequest for a customer's payment to the third-party payment service, andthe third-party payment service forwards the authorization request tothe proper entity. This entity often is one of many third-party vendorswith which the third-party payment service contracts. The entity thenobtains an approval for the authorization request—an“authorization”—from the customer's bank, etc. The authorizationconfirms that the customer indeed has money (or credit) in his or heraccount to pay for the transaction and also locks down or otherwisereserves the money (or credit) in the account.

For example, for a merchant whose bank is Wells Fargo, an authorizationrequest for payment from a customer's Visa credit card is forwarded toWells Fargo (i.e., the acquirer). Wells Fargo then obtains anauthorization for the request through VisaNet™ from the customer's bankthat issued the credit card (i.e., the issuer).

Hosted order pages and silent order posts allow a merchant to avoidcollecting customers' credit card numbers and related specifics.Instead, the third-party payment service presents the credit card entryweb page or fields for the user to enter his or her information. Becausethe merchant does not collect the information, it can avoid the burdensrelated to being payment card industry (PCI) data security standard(DSS) compliant.

There are difficulties associated with hosted order pages and silentorder posts. For one, customers prefer a seamless interface so that itappears that he or she is not being redirected to a third party in orderto make a purchase. It has also been found that seeing the orderspecifics on the payment page helps remind the customer of why he or sheis spending money, perhaps easing the purchase along. If order specificsare to be shown on a third party web site, then that information must bepackaged and sent to the third party web site. There is also thecomplication of robustly handling a user who clicks a Back or Cancelbutton on his or her web browser. With all of the difficulties, it maybe easier to keep as much of the payment selections on the merchant'sweb site as possible.

A need exists in the art for better coordination of merchant web sitesand third-party vendors that facilitate payments.

BRIEF SUMMARY

Methods and systems are disclosed for creating and using paymenttokens—which represent credit card or other payment accountnumbers—whose format is customized. The customizable formats of thetokens can include the number of characters in the token such that thetoken can be a different length than the standard 16-digit format ofpayment cards. The format can include using a combination of letters andnumbers, specifying certain characters for specific card brands, andusing encryption and/or randomization for other areas of the token.

Some embodiments of the present application are related to a method ofgenerating merchant-customizable payment tokens. The method includesreceiving from a secure web site a payment account number from acustomer for a first transaction with a merchant web site, retrieving atoken format from a database, the token format configured by a merchantassociated with the merchant web site, and generating, using at leastone processor operatively coupled to a memory, a token representing thepayment account number, the token including a plurality of characters, aportion of the token generated using a random number generator and aformat of the token conforming with the token format. The method furtherincludes receiving from the merchant web site an indication for a secondtransaction from the customer, sending to the merchant web site thetoken representing the payment account number, receiving a selection ofthe token from the merchant web site, and initiating a paymenttransaction using the payment account number based on the selection

Some embodiments are related to a method of generating customizablepayment tokens. The method includes receiving from a merchant a paymenttoken format specifying an alphanumeric field, the token formatspecifying a character length of a payment token, generating, using atleast one processor operatively coupled with a memory, a payment tokenrepresenting a payment account number, a field of the generated tokenrepresenting an encrypted portion of the payment account number andhaving at least one letter, the generating conducted in response to afirst transaction, receiving a selection of the token from a merchantweb site, and initiating a payment transaction using the payment accountnumber based on the selection

Other embodiments relate to machine-readable tangible storage media andcomputer systems that employ or store instructions for the methodsdescribed above.

A further understanding of the nature and the advantages of theembodiments disclosed and suggested herein may be realized by referenceto the remaining portions of the specification and the attacheddrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a merchant shopping cart page of the prior art.

FIG. 2 illustrates a secure third-party credit card entry web page ofthe prior art.

FIG. 3 illustrates a secure third-party web page for selecting apreviously-used card of the prior art.

FIG. 4 illustrates a merchant web page for selecting a previously-usedcard in accordance with an embodiment.

FIG. 5 illustrates a merchant defining a token format for a securethird-party in accordance with an embodiment.

FIG. 6 illustrates a customer's submitting a credit card number to asecure third party and generation of a token in accordance with anembodiment.

FIG. 7 illustrates a customer's selection of a token through a merchantin accordance with an embodiment.

FIG. 8 is a system sequence diagram of customer's first use of a card inaccordance with an embodiment.

FIG. 9 is a system sequence diagram of customer's subsequent use of acard in accordance with an embodiment.

FIG. 10 illustrates a token customization interface in accordance withan embodiment.

FIG. 11 illustrates a token format in accordance with an embodiment.

FIG. 12 illustrates a token format in accordance with an embodiment.

FIG. 13 illustrates a token format in accordance with an embodiment.

FIG. 14 illustrates a token format in accordance with an embodiment.

FIG. 15 is a flowchart of a process in accordance with an embodiment.

FIG. 16 is a flowchart of a process in accordance with an embodiment.

FIG. 17 illustrates payment authorization in accordance with anembodiment.

FIG. 18 shows a block diagram of an exemplary computer apparatus thatcan be used in some embodiments.

The figures will now be used to illustrate different embodiments inaccordance with the invention. The figures are specific examples ofembodiments and should not be interpreted as limiting embodiments, butrather exemplary forms and procedures.

DETAILED DESCRIPTION

Payment tokens whose format is customized by merchants are described. Inthe prior art, the focus was toward further standardization of cardnumber formats and related payment account identifiers. The length,character set, subset positions, and other attributes of accountidentifiers were standardized in order to facilitate transactions acrosscomputer systems.

Generating a payment token that corresponds to an account number, buthas no mathematical relation to the account number, is an unclassifiedway to refer to the account number without mentioning the accountnumber. The token can be passed from PCI DSS-compliant parties tonon-PCI DSS-compliant merchants so that the merchants can ‘store’representatives of card numbers for a customer for when he or shereturns.

FIG. 1 illustrates a merchant shopping cart page of the prior art. Acustomer uses web browser 101 in order to visit merchant web site 103.In the exemplary embodiment, web site 103 is at uniform resource locator(URL) 102. Merchant web page 103 is unsecure as indicated by broken lockicon 104. At this point, the customer has merely selected some items topurchase from the web site, and no financial data has been given.Therefore, it is not necessary for the web page to be secure.

The user can click on linked button 105 in order to “check out” and givefinancial payment data to order the selected items. Checking out takesthe customer's web browser to a secure web page of a third-party secureweb site.

FIG. 2 illustrates a secure third-party credit card entry web page ofthe prior art. Secure URL 202 is through a domain of the third-party,and its secure nature is indicated by lock icon 204. The user isprompted to enter his or her payment card information in entry area 209.After the user enters a credit card number and expiration date and hitsthe submit button, the credit card number is sent securely to thethird-party, bypassing the merchant. The merchant does not need to seethe credit card data, and—to avoid having to be PCI DSS-compliant—ittypically does not want to see the credit card number. The merchantmerely needs to be informed by the third party whether the credit cardwas authorized for the transaction amount.

After the customer's credit card is used for a purchase of the selecteditems, the credit card number is stored by the third-party web site incase the customer visits again. The customer can come back to the samemerchant web site and select items for another order.

FIG. 3 illustrates a secure third-party web page for selecting apreviously-used card of the prior art. After the customer has selecteditems from the merchant's web site, his or her web browser is redirectedto the third-party secure site. URL 302, to which the customer's webbrowser is redirect, is a secure URL, as indicated by lock icon 304.

On the secure third-party's web site, list 311 of prior cards ispresented for the user to select from. In the exemplary embodiment, theuser has used three cards previously with the same merchant. To use oneof the previously used cards, the user merely needs to select the radiobutton for the appropriate card and hit the submit button.

Additionally, linked button 312 can be pressed in order to bring up a‘new card’ dialog, similar (or the same) as the web page shown in FIG.2.

Because the third-party collects and keeps the credit card numbers, andthe merchant is not privy to the card numbers, the merchant's web siteis unable to provide the list of previously used credit card numberssuch as list 311 in the third-party secure web site. Thus, the customermust be redirected to the third-party's secure web site at URL 302 inorder to see the list of previously used payment cards. It would beuseful if the list of previously used credit cards could be selectedfrom the merchant's web site so that other details of the transactioncould be shown next to the list.

FIG. 4 illustrates a merchant web page for selecting a previously-usedcard in accordance with an embodiment. URL 402 points to a location onthe merchant's web site, and it is unsecure as indicated by broken lockicon 404. Information summary 410 about the customer's purchase is shownon the same web page as list 411 of previously used cards. The showingof previous cards as well as information on the current purchase can beaccomplished by the use of tokens that represent the card number but arenot actually the card number.

In the exemplary embodiment, three tokens, each representing adifferent, previously-used payment account, are sent from thethird-party vendor to the merchant.

The tokens contain the last four digits of the true card number but areotherwise each random sets of characters. The merchant can display thelast four digits of the card number for the customer so that thecustomer can determine which card he or she would like to use for thenext purchase. If the customer selects one of the cards, then theselected token can be sent back to the third-party secure web site, andthe third party uses the associated card number to initiate the purchaseprocessing.

The token formats can be customized by the merchant. For example, thelength of characters of the token can be set by the merchant, or thecharacter set can be specified.

Technical advantages of customizable, configurable payment tokens aremany. Common sixteen-digit card numbers are constantly being sought byidentity thieves. Sixteen-digit card numbers are relatively easy to spotas card numbers, especially if they comply with the Luhn algorithm(i.e., the “mod 10” algorithm). Numbers of lengths other than sixteenare less likely to be associated with card numbers and are thus morelikely to be overlooked by thieves. If different merchants have theirown, different token formats, then it is more difficult for identifythieves to identify tokens from intercepted data that relate to cardnumbers. Customizable card numbers also can help when using computerequipment in different countries that were once standardized ondifferent card formats. The computer systems can be re-used to work withtokens that are formatted to the old, legacy formats instead of the newcard numbers. For example, in some European countries card numbers wereten digits long. The token formats can be customized to aide internalbilling practices. For example, all Visa-branded cards can include a ‘V’in the first position so that employees of the merchant can track whichcards are being used the most. Alphanumerics can be customized fortokens so that there is a greater character set than just the numbersfrom ‘0’ to ‘9’ in the tokens.

An “alphanumeric” field includes a field that has letters and numbers,letters only, numbers only, or as otherwise known in the art.

FIG. 5 illustrates a merchant defining a token format for a securethird-party in accordance with an embodiment. Merchant 520 submits tokenformat 523 to third-party payment processor 521. Token format 523 issaved by payment processor in database 522. This can be done securelythrough the Internet to an online web site, by way of telephone to atrusted customer service representative, or otherwise.

FIG. 6 illustrates a customer's submitting a credit card number to asecure third party and the generation of a token in accordance with anembodiment. After a customer has selected items on merchant 520's website, he or she selects a checkout link that takes him or her to asecure web site of third-party payment processor. The customer usescomputer 625 to enter information from card 626 on the third-party'ssecure web site, such as card number 627. Upon submission, the user'scard number 627 is received through a secure connection by paymentprocessor 521.

Card number 627 is used to create authorization request message 680 inorder to complete the present sale. Authorization response message 681indicates whether the card payment has been accepted by an issuer.Generating the token and/or saving the token to the database can bedependent upon whether authorization response message 681 actuallyauthorizes the purchase or not. For example, the token may only begenerated if the card purchase goes through.

Upon receipt of card number 627, token generator 624 retrieves tokenformat 523 from database 522. The token generator generates token 629,which is associated with and represents card number 627. Token 629includes a portion generated using a random number generator so that itis not in any way mathematically related to the card number that itrepresents. Token 629 is saved in table 625, where its association withcard number 627 is memorialized for the next time that the user orderssomething from the merchant.

FIG. 7 illustrates a customer's selection of a token through a merchantin accordance with an embodiment. The customer uses computer 725 toselect items from merchant 520's web site and goes to the merchant'scheck out. The merchant requests tokens from the third-party so that itcan determine the cards used for the customer's previous purchases. Inthe exemplary embodiment, tokens 729 that are associated with paymentaccount numbers used in the past are sent from table 625 to merchant520. Merchant 520 redacts the tokens (i.e., X's out all but the lastfour digits) and presents them as a list of options 730 to the user forusing previous cards.

The customer uses his or her computer to select item 731 from list 730.Item 731 represents a previously-used credit card number. Item 731 issent to merchant 520, where it is associated with the full token. Forexample, if the user selected the third item in the list of previouslyused payment cards, the merchant associates the selection with the thirdtoken. Selected token 732 is sent back by merchant 520 to third-partypayment processor 521. The card number associated with selected token732 is looked up in table 625, and the card number is used for paymentauthorization request message 780. If all goes well, then authorizationresponse message indicates that the card purchase is (again) approved.

Note that at no time in the figure did a card number pass among thecustomer, merchant, and payment processor. Only ten-character tokenswere used.

FIG. 8 is a system sequence diagram of customer's first use of a card inaccordance with an embodiment. A customer's computing device sendsmessage 841 to a merchant, indicating that the customer is ready tocheck out and pay for his or her selected merchandise. In response, themerchant sends message 842 to the secure third party to get anypreviously used cards that the customer might have used. In this case,it is determined that the customer has not used any cards before. Thethird party sends message 843 back to the merchant indicating that thecustomer has not used any cards before. The merchant then sends message844 to the third party requesting that it make a connection with theuser and prompt the user for a (new) payment account number.

The third party sends credit card entry form 845 directly to thecustomer, bypassing the merchant. In response, the user dutifully typesin his or her credit card number, expiration date, etc. and his or herweb browser posts the information in message 846 back to the thirdparty. The third party then uses the card number to initiate a paymenttransaction by way of authorization request 880. Authorization responsemessage 881 can indicate that the payment transaction is authorized bythe associated issuer.

Third party requests a token format associated with the merchant fromdatabase 822 in message 849, and token format 850 is sent back to thethird party. Database 822 can be owned by the third party's, themerchant, or another party.

The fact that the payment was authorized is sent from the third party tomerchant in message 851 in order to complete the current sale.Optionally, newly generated token 852 can be sent to the merchant aswell. The merchant then sends order confirmation 853 to the customer sothat the customer knows that the card number was valid and will becharged for the selected merchandise.

FIG. 9 is a system sequence diagram of customer's subsequent use of acard in accordance with an embodiment. A customer's computing devicesends message 941 to the merchant indicating that the customer is readyto check out. In response, the merchant sends message 942 to the securethird party to get any previously used cards. In this case, it isdetermined that the customer has used one or more cards before with themerchant. Customized tokens 955 representing the previously-used cardnumbers are sent from the third party to the merchant. The merchant canthen send a ‘redacted’ list of cards, based on the received tokens, inmessage 956 (e.g., a web page) to the customer. The customer can thenselect a particular token, and his or her browser informs merchantthrough message 957 (e.g., an Hypertext Markup Language (HTML) POST).Selected token 958 is sent from the merchant to the third party, and thethird party initiates a transaction based on the card number associatedwith the token by authorization request message 980. Authorizationresponse message 981 may be received in response, indicating that thecard is accepted.

Payment authorization message 961 is sent from the third party to themerchant, and the merchant informs the user through order confirmation962.

Note that no account number was sent among the customer, merchant, orthird party in the figure. Only tokens were used. Furthermore, thecustomer was able to select from a list of previously used cards,recognizing the cards by the last four digits of the true card number,through the merchant even though the merchant never had possession ofthe full card number.

The token formats are customized for the merchant according to themerchant's preferences. The tokens are difficult for identity thieves torecognize because they are different from the standard card numbers thatare used.

FIG. 10 illustrates a token customization interface in accordance withan embodiment. A merchant can select a number of characters in section1065 of form 1000. The merchant can select whether the token will usenumbers only, letters only, or numbers and letters in section 1066. Insection 1067, a character can be used to indicate major paymentnetworks. For example, a ‘V’ can represent Visa. Other characters can beused for other major payment networks.

The last four digits of the true card number can be replicated in thelast four digits of the token in section 1068. This has become astandard way for users to recognize their own card numbers. In section1069, the remaining portions of the token can be a random number or anencryption of the whole or part of the card number.

FIG. 11 illustrates a token format in accordance with an embodiment. Thefirst twelve digits of a sixteen-digit card number are encrypted asother digits and pre-pended on the last four digits of the card number.This results in a sixteen-digit number that is similar in format tostandard payment account numbers.

The encryption may break the checksum for card number. The checksum,calculated through the Luhn algorithm, is sometimes referred to as “mod10 compliance,” and ensures the integrity of a card number. If a hackersearches for sixteen-digit sequences of numbers that are mod 10compliant, the hacker will not find those associated with thesesixteen-digit tokens. Meanwhile, the sixteen-digit tokens can be usedwith legacy equipment on the merchant's end.

The first six digits of a standard sixteen-digit card number aresometimes referred to as an Issuer Identification Number (IIN) (formerlyBank Identification Number (BIN)). Like the last four digits of the cardnumber, the IIN digits can be preserved, encrypted, or replaced withrandom characters.

FIG. 12 illustrates a token format in accordance with an embodiment. Theformat of the token includes both numbers and letters. A random sequenceof numbers and letters is generated for the first twelve characters ofthe token, and the last four digits are again the same digits as thosein the card number.

FIG. 13 illustrates a token format in accordance with an embodiment. Atwenty-two character token includes both characters and numbers as wellas a character (i.e., the thirteenth character) reserved to indicate themajor payment network. The last four digits of the card number are notcopied to the token.

FIG. 14 illustrates a token format in accordance with an embodiment. Thefirst character is reserved to indicate the major payment network, andthe last four digits are those of the card number. Characters twothrough six of the ten-character token are an encrypted version of thefirst twelve digits of the card number.

Other formats are possible using different selections. For example, amerchant may wish to add mod 10 compliance to numeric tokens, or amerchant may wish for non-number and non-letter characters, such as ‘*,’‘],’ and ‘˜,’ to be available for use in the tokens. Characters caninclude those specified by the American Standard Code for InformationExchange (ASCII) or as otherwise known in the art.

FIG. 15 is a flowchart of a process in accordance with an embodiment.Process 1500 can be implemented by a computer or other machine. Inoperation 1501, a payment account number from a customer for a firsttransaction with a merchant web site is received from a secure web site.In operation 1502, a token format is received from a database, the tokenformat configured by a merchant associated with the merchant web site.In operation 1503, a token representing the payment account number isgenerated using at least one processor operatively coupled to a memory,the token including a plurality of characters, a portion of the tokengenerated using a random number generator and a format of the tokenconforming with the token format. In operation 1504, an indication for asecond transaction from the customer is received from the merchant website. In operation 1505, the token representing the payment accountnumber is sent to the merchant web site. In operation 1506, a selectionof the token is received from the merchant web site. In operation 1507,a payment transaction is initiated using the payment account numberbased on the selection.

FIG. 16 is a flowchart of a process in accordance with an embodiment.Process 1600 can be implemented by a computer or other machine. Inoperation 1601, a payment token specifying an alphanumeric field isreceived from a merchant, the token format specifying a character lengthof a payment token. In operation 1602, a payment token representing apayment account number is generated using at least one processoroperatively coupled with a memory, a field of the generated tokenrepresenting an encrypted portion of the payment account number andhaving at least one letter, the generating conducted in response to afirst transaction. In operation 1603, a selection of the token isreceived from a merchant web site. In operation 1604, a paymenttransaction is initiated using the payment account number based on theselection.

Example embodiments are typically implemented in the context of apayment transaction. Therefore, prior to further discussing exemplarysystems for enriching transaction data with interchange data fortransactions conducted across multiple payment processing networks, abrief description of typical payment processing using a standard paymentprocessing system is presented below.

FIG. 17 illustrates payment authorization in accordance with anembodiment. A standard payment processing system 1710 may include a user1710, a consumer device 1712, a merchant computer 1714, a paymentprocessor 1715, an acquirer computer 1716, a payment processing network1718, and an issuer computer 1720. In a typical purchase transaction, auser 1710 may purchase goods or services at a merchant using a consumerdevice 1712 such as a laptop computer, smart phone, etc.

An authorization request message may then be transmitted in response toinstructions from a merchant computer 1714 from a payment processorcomputer 1715 to an acquirer computer 1716. After receiving theauthorization request message, the acquirer computer 1716 may thentransmit the authorization request message to a payment processingnetwork 1718. The payment processing network 1718 may then forwards theauthorization request message to an issuer computer 1722 associated withthe portable consumer device 1712.

After the issuer computer 1722 receives the authorization requestmessage, the issuer computer 1722 may generate and send an authorizationresponse message to the payment processing network 1718 indicatingwhether or not the transaction was approved. The payment processingnetwork 1718 may transmit the authorization response message to theacquirer computer 1716 which may then transmit the authorizationresponse message back to the payment processor 1715.

FIG. 18 shows a block diagram of an exemplary computer apparatus thatcan be used in some embodiments. The subsystems shown in the figure areinterconnected via a system bus 1810. Additional subsystems such as aprinter 1808, keyboard 1818, fixed disk 1820 (or other memory comprisingtangible computer readable media), monitor 1814, which is coupled todisplay adapter 1812, and others are shown. Peripherals and input/output(I/O) devices, which couple to I/O controller 1802, can be connected tothe computer system by any number of means known in the art, such asserial port 1816. For example, serial port 1816 or external interface1822 can be used to connect the computer apparatus to a wide areanetwork such as the Internet, a mouse input device, or a scanner. Theinterconnection via system bus allows the central processor 1806 tocommunicate with each subsystem and to control the execution ofinstructions from system memory 1804 or the fixed disk 1820, as well asthe exchange of information between subsystems. The system memory 1804and/or the fixed disk 1820 may embody a tangible computer readablemedium.

It should be understood that the present invention as described abovecan be implemented in the form of control logic using computer softwarein a modular or integrated manner. Based on the disclosure and teachingsprovided herein, a person of ordinary skill in the art will know andappreciate other ways and/or methods to implement the present inventionusing hardware and a combination of hardware and software.

Any of the software components or functions described in thisapplication, may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C++ or Perl using, for example, conventional or object-orientedtechniques. The software code may be stored as a series of instructions,or commands on a computer readable medium, such as a random accessmemory (RAM), a read only memory (ROM), a magnetic medium such as ahard-drive or a floppy disk, or an optical medium such as a CD-ROM. Anysuch computer readable medium may reside on or within a singlecomputational apparatus, and may be present on or within differentcomputational apparatuses within a system or network.

The above description is illustrative and is not restrictive. Manyvariations of the invention will become apparent to those skilled in theart upon review of the disclosure. The scope of the invention should,therefore, be determined not with reference to the above description,but instead should be determined with reference to the pending claimsalong with their full scope or equivalents.

One or more features from any embodiment may be combined with one ormore features of any other embodiment without departing from the scopeof the invention.

A recitation of “a”, “an” or “the” is intended to mean “one or more”unless specifically indicated to the contrary.

All patents, patent applications, publications, and descriptionsmentioned above are herein incorporated by reference in their entiretyfor all purposes. None is admitted to be prior art.

1.-20. (canceled)
 21. A method comprising: providing, by a usercomputer, via a graphical user interface operated by a user, auser-configured token format to a payment processor computer; providing,by a merchant computer, an authorization request message comprising apayment account number to the payment processor computer, which forwardsthe authorization request message to an issuer computer, which returnsan authorization response message with an authorization to the paymentprocessor computer, the payment processor computer determining that theauthorization response message contains the authorization and generatinga token associated with the payment account number, wherein the tokenconforms to the user-configured token format; receiving, by the merchantcomputer, the authorization response message comprising theauthorization from the payment processor computer, the authorizationresponse message comprising the token associated with the paymentaccount number; and storing, by the merchant computer, the token. 22.The method of claim 21 further comprising: transmitting, by the merchantcomputer, the token to the payment processor computer in a secondauthorization request message, wherein the payment processor computerdetermines the payment account number associated with the token,forwards the second authorization request message to the issuer computerwith the payment account number and without the token, and receives anauthorization response message with the payment account number andwithout the token, and forwards an authorization response message withthe token and without the payment account number to the merchantcomputer; and receiving, by the merchant computer, the secondauthorization response message comprising the token.
 23. The method ofclaim 22 wherein the specified total number of characters for the tokenis different than a number of total characters of the payment accountnumber.
 24. The method of claim 21 wherein the generating the tokenincludes: encrypting a portion of the payment account number; andbuilding the token using the encrypted portion of the payment accountnumber.
 25. The method of claim 21 wherein the user-configured tokenformat specifies one or more characters indicating a particular paymentnetwork.
 26. The method of claim 21 wherein the user-configured tokenformat specifies that only letters are in the tokens to be generated.27. The method of claim 21 wherein the user-configured token formatspecifies that only numbers are in the tokens to be generated.
 28. Themethod of claim 21 wherein the payment account number identifies anaccount associated with a card selected from the group consisting of acredit card, debit card, and prepaid card.
 29. The method of claim 21wherein the generated token is not mod 10 compliant.
 30. The method ofclaim 21 wherein the user-configured token format further specifies aposition where a portion of the token is generated using a random numbergenerator.
 31. A computer system comprising: a processor; and a computerreadable medium comprising code, executable by the processor, toimplement a method comprising providing via a graphical user interfaceoperated by a user, a user-configured token format to a paymentprocessor computer; providing an authorization request messagecomprising a payment account number to the payment processor computer,which forwards the authorization request message to an issuer computer,which returns an authorization response message with an authorization tothe payment processor computer, the payment processor computerdetermining that the authorization response message contains theauthorization and generating a token associated with the payment accountnumber, wherein the token conforms to the user-configured token format;receiving the authorization response message comprising theauthorization from the payment processor computer, the authorizationresponse message comprising the token associated with the paymentaccount number; and storing the token.
 32. The computer system of claim31, wherein the method further comprises: transmitting the token to thepayment processor computer in a second authorization request message,wherein the payment processor computer determines the payment accountnumber associated with the token, forwards the second authorizationrequest message to the issuer computer with the payment account numberand without the token, and receives an authorization response messagewith the payment account number and without the token, and forwards anauthorization response message with the token and without the paymentaccount number to the merchant computer; and receiving the secondauthorization response message comprising the token.
 33. The computersystem of claim 32 wherein the specified total number of characters forthe token is different than a number of total characters of the paymentaccount number.
 34. The computer system of claim 31 wherein thegenerating the token includes: encrypting a portion of the paymentaccount number; and building the token using the encrypted portion ofthe payment account number.
 35. The computer system of claim 31 whereinthe user-configured token format specifies one or more charactersindicating a particular payment network.
 36. The computer system ofclaim 31 wherein the user-configured token format specifies that onlyletters are in the tokens to be generated.
 37. The computer system ofclaim 31 wherein the user-configured token format specifies that onlynumbers are in the tokens to be generated.
 38. The computer system ofclaim 31 wherein the payment account number identifies an accountassociated with a card selected from the group consisting of a creditcard, debit card, and prepaid card.
 39. The computer system of claim 31wherein the generated token is not mod 10 compliant.
 40. The computersystem of claim 31 wherein the user-configured token format furtherspecifies a position where a portion of the token is generated using arandom number generator.